Systems and methods of direct account transfer

ABSTRACT

A financial institution and a payment initiator may exchange public keys to enable the secure exchange of data. A business wishing to collect payment can provide its account information to the payment initiator. A customer wishing to pay can instruct the payment initiator to encrypt the business&#39;s account information along with details for a particular invoice and transmit the information to the financial institution. The financial institution can decrypt the information and initiate a transfer of money from the customer to the business. The financial institution may present the information about the transaction to the customer for modification or confirmation before initiating the transfer. The information may be sent from the payment initiator to the financial institution via the customer. After the payment has been initiated by the financial institution, a confirmation may be sent to the customer, the payment initiator, the business, or any suitable combination thereof.

CLAIM OF PRIORITY UNDER 35 U.S.C. 120

The application claims priority to and incorporates by reference U.S.application Ser. No. 14/446,782, filed Jul. 30, 2014, entitled “Systemsand Methods of Direct Bank Transfer,” which claimed priority from U.S.Provisional Application No. 61/860,771, filed Jul. 31, 2013, entitled“Systems and Methods of Direct Bank Transfer.”

TECHNICAL FIELD

The present disclosure generally relates to monetary transfers and, morespecifically, to systems and methods for facilitating direct accounttransfers.

BACKGROUND

Merchants send invoices to customers with information regarding moneyowed by a customer to a merchant. A customer pays an invoice by writinga check, using a credit card, transferring money via a third party, ortransferring money from a customer bank account to a merchant bankaccount. Money transfers between banks may be performed using theAutomated Clearing House (ACH).

To make an ACH transfer, a customer connects to a server associated withhis or her bank, enters the transaction details, and submits thetransfer request. The money is transferred directly to the merchantaccount from the customer account via ACH.

To transfer money via a third party, the customer connects to a serverassociated with the third party, enters the transaction details, andsubmits the transfer request. The money is transferred from the customeraccount to an account of the third party and then from the third-partyaccount to the merchant account.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not of limitationin the figures of the accompanying drawings.

FIG. 1 is a block diagram depicting an example single ledger accountingplatform, according to some embodiments.

FIG. 2 is a block diagram depicting an example accounting applicationframework for the accounting platform, according to some embodiments.

FIG. 3 is a block diagram depicting an example hosting infrastructurefor the accounting platform, according to some embodiments.

FIG. 4 is a block diagram depicting an example data center system of theaccounting platform, according to some embodiments.

FIG. 5 is a block diagram depicting an example client device foraccessing the accounting platform, according to some embodiments.

FIG. 6 is an interface diagram depicting an example user interface (UI)displaying accounts accessible by a user of the accounting platform,according to some embodiments.

FIG. 7 is an interface diagram depicting an example user interface forcreating an invoice from a business, according to some embodiments.

FIG. 8 is an interface diagram depicting an example user interfacedisplaying an invoice from a business, according to some embodiments.

FIG. 9 is an interface diagram depicting an example user interface forconfiguring bank options, according to some embodiments.

FIG. 10 is an interface diagram depicting an example user interface forpaying an invoice from a business, according to some embodiments.

FIG. 11 is a block diagram depicting the flow of data between entitiesfacilitating a transfer of funds, according to some embodiments.

FIG. 12 is a flowchart of an example method for facilitating direct banktransfers, according to some embodiments.

FIG. 13 is a flowchart of an example method for facilitating direct banktransfers, according to some embodiments.

FIG. 14 is a block diagram of a machine in the example form of acomputer system within which a set of instructions, for causing themachine to perform any one or more of the methodologies discussedherein, may be executed, according to some embodiments.

DETAILED DESCRIPTION

Example systems and methods to facilitate direct bank transfers aredescribed. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of example embodiments. It will be evident, however, toone skilled in the art that the present technology may be practicedwithout these specific details.

The technology described herein provides online accounting software tobusinesses with features such as a payment mechanism available to abusiness's customers, where the payment mechanism may drive paymentsthrough a bank rather than third-party payment services (e.g., creditcard transaction processors, PayPal, and so on). In some embodiments,financial institutions may also use such payment features to let trustedpartners submit payments to them for confirmation and processing.

The financial institution and the payment initiator may exchange publickeys, to enable the secure exchange of data. The business provides itsaccount information to the payment initiator. The payment initiator canencrypt the account information along with details for a particularinvoice (such as payment amount and payment date) and transmit theinformation to the financial institution. The financial institution candecrypt the information and initiate a transfer of money from one of thecustomer's bank accounts to the business on the payment date. In someexample embodiments, the financial institution presents the informationabout the transaction to the customer for modification or confirmationbefore initiating the transfer. In some example embodiments, thefinancial institution allows the customer to confirm or cancel thetransaction, but not to modify it. For example, the payment initiatormay include one or more flags in the data to indicate whether thevarious prepopulated fields for the transaction (e.g., payment amount,payment date, and so on) can be modified by the customer. Based on theflags, the financial institution can modify the options presented to thecustomer.

The information may be sent from the payment initiator to the financialinstitution via the customer. For example, the encrypted data may besent from a web site of the payment initiator to a web browser of thecustomer running on a customer device. After the payment has beeninitiated by the financial institution, a confirmation may be sent tothe customer, the payment initiator, the business, or any suitablecombination thereof.

FIG. 1 is a block diagram depicting an example single ledger accountingsystem 100. A single ledger accounting system 100 may provide accountingtools to a particular entity managing accounting for one or morebusinesses. The example single ledger accounting system 100 may includea practice studio 110 that allows an entity to manage one or morebusinesses and an organization access module 150 that provides abusiness with tools for managing accounting data for that particularbusiness. The practice studio 110 may include a practice staffmanagement module 114, an online training module 116, a partnerresources module 120, a report packs setup module 122, and a work papersmodule 124. The practice studio 110 may be in communication with corefeatures 130. The core features 130 may include an accounting andpayroll module 132, a community module 134, a billing/subscriptionmanagement module 136, a notifications center module 138, a user profilemanagement module 140, and a login module 142. The organization accessmodule 150 may be in communication with the core features 130. Thepractice studio 110 and core features may be accessed by an entity usinga login module 142.

As shown in FIG. 1, features of the system 100 are divided into threeareas based on the target user. The features of the practice studio 110provide a suite of tools for accountants to interact with their clientsand manage their practices. The core features 130 provide the corefunctionality and user tools common to both accountants and businesses.The organization access 150 provides a user interface for individualbusinesses to access their data.

Practice studio 110 is the central login for accountants. For example,an accountant with multiple clients, each of which is a small business,can login using practice studio 110 and gain access to the accountingdata for the clients, messages from the clients, and so on.

The practice staff management module 114 provides the ability for themanager of an accounting practice to control settings for the staff ofthe practice. For example, some staff members may have read-only accessto data for certain clients, some staff members may have read-writeaccess for certain clients, some staff members may be able to modify theaccess permissions for other staff members, and so on.

The online training module 116 provides training for accountants andtheir staff. In some cases, the provided training includes one or morevideo presentations and one or more online tests. Notification ofpassing a test at completion of a training may be provided. For example,a staff member may take a training course and, upon successfulcompletion, the accountant supervising the staff member may receive anotification of the successful completion.

The partner resources module 120 provides information regardingthird-party partners. For example, a third party may provide tools thatinteract with the system to provide useful functionality beyond that ofthe system alone. The user can access the partner resources module 120to learn about available third-party tools. For example, links tothird-party websites, documentation, videos, and search tools may all beprovided.

The report packs setup module 122 provides tools to allow accountants tocreate and generate standardized sets of reports. For example, a profitand loss statement and quarterly report could both be added to a pack.The accountant would then be able to easily generate both reports forany selected client, or generate the reports for every client.

The work papers module 124 provides tools for accountants tointeractively create financial reports. For example, an accountant canenter known data for a client into the work paper, and then send thework paper to the client with an indication of data needed from theclient. After the client enters the missing data into the work paper,the accountant can complete the report.

The core features 130 includes modules that are used both by accountantsand organizations. The accounting and payroll module 132 provides thegeneral ledger for organizations. The general ledger may be integratedwith the organization's payroll, bypassing the separate step of enteringpayroll data into the general ledger each pay period. The accounting andpayroll module 132 accesses banking data for each client business. Thebanking data may be imported into either through a bank feed or a user-or accountant-created document. The accounting and payroll module 132may also communicate with third-party tools via an application protocolinterface (API).

The community module 134 provides a forum through which users cancommunicate. For example, a user with a question may post a topic in theforum and later receive a helpful response from another user.Information taken from the user profile (e.g., the user profile managedvia the user profile management module 140) may appear along with forumposts by the user. For example, a user name, an image of the user, andthe user's status as an accountant or member of an organization may eachbe shown.

The billing/subscription management module 136 allows a user toconfigure one or more billing accounts for each organization using thesystem. The system may periodically charge a subscription fee for access(e.g., a monthly or annual subscription fee). The subscription fee maybe automatically deducted from the one or more billing accounts.

The notifications center module 138 provides notifications to users. Forexample, users may send messages to each other, which appear asnotifications. Notifications may also be created by the system (e.g., byaccounting and payroll module 132) based on events. For example, aminimum account balance for a particular bank account may be set by auser via the accounting & payroll module 132. When the balance for thatbank account drops below the minimum account balance, a notification canbe generated by the system informing the user.

The user profile management module 140 allows a user to manage theprofile of the user's organization and the profiles of others based onpermission settings. For example, an accountant may have permission tomanage the profiles of the accountant's clients. The profile may includepublic-facing information such as a business name and address.

The login module 142 verifies the identify of a user logging into thesystem (e.g., via user name and password). Based on the user's identity,a user interface is presented that includes a list of organizations thata user has access to. For most small business clients, the list willconsist of a single organization.

The organization access module 150 accesses the core features 130 for asingle organization. The organization access module 150 presents, afteruser verification by the login module 142, a user interface with optionsfor a single organization without the additional features used only bythe practice studio 110.

FIG. 2 is a block diagram depicting an example accounting applicationframework 200 for the accounting platform. The accounting applicationframework 200 may be an end-to-end web development framework enabling a“software as a service” (SaaS) product. The accounting applicationframework 200 may include a hypertext markup language (HTML) and/orJavaScript layer 210, ASP.Net Model-View-Controller (MVC) 220,extensible stylesheet language transformations (XSLT) 230, construct240, services 250, object relational module 260, and database 270.

The HTML and/or JavaScript layer 210 provides client-side functionality,such as UI generation, receipt of user input, and communication with aserver. The client-side code may be created dynamically by the ASP.NETMVC 220 or the XSLT 230. Alternatively, the client-side code may bestatically created or dynamically created using another server-sidetool.

The ASP.Net MVC 220 and XSLT 230 provide server-side functionality, suchas data processing, web page generation, and communication with aclient. Other server-side technologies may also be used to interact withthe database 270 and create an experience for the user.

The construct 240 provides a conduit through which data is processed andpresented to a user. For example, the ASP.Net MVC 220 and XSLT 230 canaccess the construct 240 to determine the desired format of the data.Based on the construct 240, client-side code for presentation of thedata is generated. The generated client-side code and data forpresentation is sent to the client, which then presents the data.

The services 250 provide reusable tools that can be used by the ASP.Net220, the XSLT 230, and the construct 240 to access data stored in thedatabase 270. For example, aggregate data generated by calculationsoperating on raw data stored in the database 270 may be made accessibleby the services 250.

The object relational model 260 provides data structures usable bysoftware to manipulate data stored in the database 270. For example, thedatabase 270 may represent a many-to-one relationship by storingmultiple rows in a table, with each row having a value in common. Bycontrast, the software may prefer to access that data as an array, wherethe array is a member of an object corresponding to the common value.Accordingly, the object relational model 260 may convert the multiplerows to an array when the software accesses them and perform the reverseconversion when the data is stored.

FIG. 3 is a block diagram depicting an example hosting infrastructure300 for the accounting platform. The platform may be implemented usingone or more pods 310. Each pod 310 includes application server virtualmachines 320 (shown as application server virtual machines 320 a-320 cin FIG. 3) that are specific to the pod 310 as well as applicationserver virtual machines (VMs) that are shared between pods 310 (e.g.,the internal services VM 330 and the application protocol interface VM340). The application server virtual machines 320-340 communicate withclients and third-party applications via a web interface or an API. Theapplication server virtual machines 320-340 are monitored by applicationhypervisors 350. An internal firewall 360 ensures that only approvedcommunications are allowed between a database hypervisor 370 and thepublically-accessible virtual machines 320-340. The database hypervisor370 monitors the primary SQL servers 380 a and 380 b. The primary SQLservers 380 a and 380 b access the shared storage layer 450 a or 450 b(shown in FIG. 4) to read and write data generated by or used by theapplication server virtual machines 320-340. The redundant SQL servers390 a and 390 b provide backup functionality for the primary SQL servers380 a and 380 b, respectively.

The virtual machines 320-340 can be implemented using Windows 2008 R2,Windows 2012, or another operating system. The application and supportservers supporting the virtual machines 320-340 can be built usingspares for redundancy. The support servers can be shared across multiplepods 310. The application hypervisors 350, internal firewall 360, anddatabase hypervisor 370 may span multiple pods 310 within a data center.In some example embodiments, each primary SQL server 380 and redundantSQL server 390 is configured to support 30,000-45,000 organizations.Accordingly, in embodiments using two such server pairs per pod 310, thepod capacity is 60,000-90,000 organizations. The redundant SQL servers390 may take advantage of the “always on” resilience feature of SQL2012.

FIG. 4 is a block diagram depicting an example data center system 400 ofthe accounting platform interacting with other systems over a network.The primary data center 410 services customer requests and is replicatedto the secondary data center 420. The secondary data center 420 may bebrought online to serve customer requests in case of a fault in theprimary data center 410. The primary data center 410 communicates over anetwork 455 with bank server 460, third party server 470, client device480, and client device 490. The bank server 460 provides banking data(e.g., via the banking application 465). The third party server 470 isrunning third party application 475. Client devices 480 and 490 interactwith the primary data center 410 using web client 485 and programmaticclient 495, respectively.

Within each data center 410 and 420, a plurality of pods, such as thepod 310 of FIG. 3, are shown. The primary data center 410 is showncontaining pods 440 a-440 d. The secondary data center 420 is showncontaining pods 440 e-440 h. The applications running on the pods of theprimary data center are replicated to the pods of the secondary datacenter. For example, EMC replication (provided by EMC Corporation) incombination with VMWare site recovery manager (SRM) may be used for theapplication layer replication. The database layer handles replicationbetween the storage layer 450 a of the primary data center and thestorage 450 b of the secondary data center. Database replicationprovides database consistency and the ability to ensure that alldatabases are at the same point in time.

The data centers 410 and 420 use load balancers 430 a and 430 b,respectively, to balance the load on the pods within each data center.The data centers 410 and 420 can be created using identical hardware toensure that the performance of the secondary data center 420 is the sameas the performance of the primary data center 410. The storage 450 a and450 b may be implemented using one or more storage area networks such asthe VNX storage area networks from EMC.

The bank server 460 interacts with the primary data center 410 toprovide bank records for bank accounts of the client. For example, theclient may provide account credentials to the primary data center 410,which the primary data center 410 uses to gain access to the accountinformation of the client. The bank server 460 can provide the bankingrecords to the primary data center 410 for later reconciliation by theclient using the client device 480 or 490.

The third party server 470 may interact with the primary data center 410and the client device 480 or 490 to provide additional features to auser of the client device 480 or 490. For example, a user may authorizethe third party server 470 to access the user's data stored in theprimary data center 410. The third party application 475 of the thirdparty server 470 may use the user's data to generate reports, providemacros, or otherwise improve the user's ability to access or manipulatethe user's data. The third party application 475 may communicate withthe primary data center 410 via the network 455 using an API. The thirdparty application 475 may communicate with the client device 480 or 490using a web or programmatic interface.

FIG. 5 is a block diagram 500 illustrating components of a client devicesuitable for mobile banking reconciliation, according to some exampleembodiments. The client device 480 or 490 is shown as including acommunication module 510, a display module 520, an input module 530, anda reconciliation module 540, configured to communicate with each other(e.g., via a bus, shared memory, or a switch).

The communication module 510 may communicate with the primary datacenter 410, the third party server 470, the network 455, or any suitablecombination thereof. Information received via the communication module510 may be presented (e.g., displayed on a display device) via thedisplay module 520. Information may be selected or search queries may beentered by a user of the client device 480 or 490.

A user interface is presented by the display module 520. The input fromthe user is detected by the input module 530. Commands received from theuser by the input module 530 may be communicated to the primary datacenter 410 by the communication module 510. The communication module 510may receive a response from the primary data center 410 that includes aset of banking records, a set of business records, associations betweenindividual banking records and individual business records that indicatereconciliation between those records, and other data, in anycombination.

The reconciliation module 540 can generate requests to the primary datacenter 410 to indicate that a banking record is reconciled by one ormore business records. The request can be communicated to the primarydata center 410 via the communication module 510, over the network 455.

FIG. 6 is an interface diagram depicting an example user interface 600displaying accounts accessible by a user of the accounting platform. Theelements 660 a-660 e are individual rows of data with information aboutdifferent businesses and may be referred to collectively as elements660. Similarly, an individual one of the elements 660 may be referred toas an element 660.

An element 605 shows the name of a logged-in user along with adownward-pointing arrow. The name or arrow may be operable to cause thedisplay of a user profile menu. For example, the user may be able tochange a contact email address, a password, and other individualinformation about the user.

An element 610 shows the name of the current application interface. Inthe example shown, the name is “My Xero.” The element 610 may be used todistinguish between access by an organization (e.g., access via theorganization access module 150) and access by an accounting practice(e.g., access via the practice studio 110).

Elements 615-630 may be operable to cause the display of additional userinterface options. For example, element 615, labeled “Billing,” may beoperable to cause the display of a billing interface that allows theuser to enter time-tracking information for use by the accounting andpayroll module 132. The element 620, labeled “Staff,” may be operable tobring up a staff interface that allows the user to control permissionsfor staff members. The functions of the staff interface may beimplemented by the practice staff management module 114. The element625, labeled “Training,” may be operable to bring up a traininginterface that allows the user to schedule training sessions or reviewthe results of training sessions. For example, the user may be enabledto set up a particular training session for a particular staff member.The element 630, labeled “Settings,” may be operable to bring up asettings interface that allows the user to modify settings for theorganization. For example, the organization may have a billing accounton file that is used to pay for subscription access to the application.The settings interface can be used to add or change the billing account(e.g., using the billing/subscription management module 136).

Element 635 displays the name of the accountant for the organization. Insome example embodiments, a logo for the accounting firm is alsodisplayed.

Element 640 displays the currently selected organization and the lasttime data for the organization was updated.

Element 645 is a search box. The user may enter one or more search termsinto the search box to cause the system to search for organizationsmatching the search terms.

Element 650, labeled “Group,” allows the user to select multipleorganizations and put them into a custom group. Operations may then beperformed on the group. For example, a report pack may be run on everyorganization in a selected group.

Element 655 is a header for the elements 660 with information regardingorganizations to which the user has access. The element 655 shows thateach element 660 has a name, a date on which it was last viewed, anaccess permission, and subscription data. For example, the name of theorganization for element 660 a is Aaron Construction. Element 660 afurther shows that Aaron Construction was last viewed today at 9:22 AM.As also shown in element 660 a, the current user is a financial advisorfor Aaron Construction, and has the appropriate access privileges tomanage users. Similarly, element 660 a shows that Aaron Construction hasa “Large” subscription. The word “View” in the element 660 a may beoperable to view subscription information for Aaron Construction.

Additional information about the available organizations may be shown inthe elements 660. For example, the elements 660 b, 660 d, and 660 e eachshow a number of unreconciled lines. This may suggest to the user thatfurther reconciliation of banking and business records is needed for thecorresponding organizations: Cafe 88 East, Artisan Kitchens, and HawkerFoods.

The elements 660 show at least a subset of the accounts to which theuser has access. For example, the accounts may be associated with one ormore organizations for which the user manages a business. The user mayclick on a link associated with one of the businesses to access andmanage accounting information associated with that business.

FIG. 7 is an interface diagram depicting an example user interface 700creating an invoice from a business. The user interface 700 includeselements 710-790, discussed in more detail below, and may be presentedto a business user for creating an invoice for a customer.

Element 710 is a button operable to create the invoice according to theoptions selected and information entered by the business user in theother elements of the UI 700. For example, operation of element 710 maycause the payment initiator to contact the customer (e.g., by email,text message, over a social network, and so on) with informationregarding the invoice. For example, an HTML web link may be provided tothe customer, operable to cause the display of UI 800, shown in FIG. 8.In some example embodiments, element 710 is also operable to save thework in progress on an invoice without actually sending the invoice tothe customer. Alternatively or additionally, another element is used tosave the work in progress.

Element 720 displays the total amount of the invoice. The currency inwhich the total is denominated may be determined by a setting of thebusiness user (e.g., to denominate all invoices in dollars), determinedautomatically based on the address of the business user (e.g., todenominate invoices in New Zealand dollars based on the business user'saddress being in New Zealand), determined by a setting of the customer(e.g., to denominate all invoices for the customer in Euros), determinedautomatically based on an address of the customer (e.g., to denominateinvoices to the customer in Rubles based on the customer's address beingin Russia), determined by a per-customer setting of the business user(e.g., to denominate all invoices for the customer from this business inPesos), or any suitable combination thereof (e.g., to denominateinvoices in an automatically-determined currency unless overridden by anexplicit setting).

Element 730 displays the name of the customer. Element 730 may beimplemented as a drop-down list or other selector, enabling the businessuser to select the customer.

Element 740 displays the type of invoice. Element 740 may be implementedas a drop-down list or other selector, enabling the business user toselect the type of invoice.

Element 750 displays a logo for the business. For example, the element750 shows an oversized and italicized version of an example companyname, “Demo Co.” Element 750 may be operable to cause the upload of animage file to use for the logo. For example, clicking on element 750 maycause the presentation of a file selector interface. The business usercan then select an image file to use for the logo. After selecting thefile, the file is transferred to the server and the image or text shownin element 750 is replaced by the uploaded image. Other ways ofselecting or uploading images may also be used. In some exampleembodiments, text, either formatted or plain, is used in addition to orin place of an image.

Element 760 shows the mailing address of the customer. The informationin element 760 may be automatically generated based on the selection ofthe customer using element 730. Alternatively or additionally, thebusiness user may be enabled to edit or populate the information inelement 760. For example, element 760 may be a text field, directlyeditable by the business user. As another example, a selection ofelement 760 can be detected. Responsive to the selection, an editinginterface may be presented to the business user. After editing theaddress information for the customer, the customer's address may beupdated for the business user. When editing a later invoice for the samecustomer, the updated address may be retrieved.

Element 770 shows metadata regarding the invoice. As shown, element 770includes an invoice number, a reference name, a goods and services tax(GST) number, an issued date, and a due date. Some or all of themetadata may be automatically generated. For example, the invoice numbermay be generated by automatically incrementing the most recently usedinvoice number. As another example, the GST number of a business may bethe same for all customers, and populated from information about thebusiness in a database. Similarly, the issued date may be pre-populatedwith the current date, and the due date may be calculated based on apre-determined grace period (e.g., 30, 60, or 90 days). Optionally, someor all of the metadata may be created or edited by the business user.

Element 780 shows item detail data for the invoice. For each item, adescription, a quantity, a unit price, and an amount is shown. Selectingan item description may cause a drop-down menu or other selector toappear. Using the selector, a different item may be chosen. When adifferent item is chosen, the description, unit price, and amount may beautomatically updated. For example, if the “Golf balls—white single”with a unit price of 4.87 is replaced by “Golf balls—black triple” witha unit price of 15.00, the amount can be automatically calculated as600.00, based on the unchanged quantity and updated unit price. In someexample embodiments, the description, quantity, and unit price fieldsallow for direct entry of data, instead of or in addition to selectionof items from an item database. The unit price for each item may beconverted automatically from a currency in which the price is stored tothe currency being used for the invoice. For example, if the unit pricesare stored in a database denominated in NZD, but the invoice is beinggenerated in US dollars, a current exchange rate between the twocurrencies can be accessed and used to convert the price.

Also shown in element 780 is an icon in the lower right-hand corner. Theicon may be operable to cause the addition of an additional row of itemdata to the invoice. In some example embodiments, a blank row is addedto the invoice each time the last row is used, allowing the businessuser to add items as needed.

Element 790 shows total detail data for the invoice. As shown in element790, the subtotal, GST, and amount due are shown. The specific lineitems shown in element 790 may vary based on the location of thebusiness user, the location of the customer, and business user options.For example, one business may choose to include a shipping cost as anitem included in the subtotal while another business may choose toinclude the shipping cost as an additional charge included in the totalbut excluded from the subtotal. The subtotal may be determined bysumming the amounts shown in element 780. Accordingly, subtotal may beautomatically updated whenever an item is added or changed in theelement 780. Alternatively or additionally, a UI element operable tocause the updating may be presented. The GST may be calculated based ontax rules for the location of the business. The amount due may bedetermined by summing the line items in element 790.

A business using the online accounting software may have the ability topresent online invoices to their customers, making the invoicing processmore efficient. The business may send out an invoice and know when ithas been seen by the customer. If a business has set up a paymentservice, their debtor may make payment through the invoice.

FIG. 8 is an interface diagram depicting an example user interface 800displaying an invoice from a business. The user interface 800 includeselements 805-870, described in more detail below. The UI 800 may bepresented in response to an activation of a link sent to the user onrequest of the business expecting payment on the invoice. Alternatively,the UI 800 may be presented in response to a login by the user to theaccounting system, based on a determination that the user hasoutstanding invoices to respond to. Multiple instances of the UI 800 maybe presented in sequence when multiple invoices are pending.Alternatively, an additional UI (not shown) may be presented, allowingthe user to select between the pending invoices.

Element 805 is a button, which a user (e.g., a business's customer) mayselect to be redirected to a bank site in order to pay the invoice. Inthe example shown in FIG. 8, the business Demo Co. (as shown by element835) may be owed a particular amount for a good or service the businessDemo Co. provided to their customer Bayside Club (as shown by element845). The user interface 800 may present the invoice associated withthis outstanding amount owed, and the customer may use the button 805 toinitiate payment directly through the customer's bank account.

Element 810 displays the total amount of the invoice. Elements 815 and820 are operable to cause the downloading or saving of the invoice inone of a variety of formats. For example, element 815 may be operable toselect the format of the download (e.g., as portable document format(PDF), comma-separated value (CSV), text, Word, etc.), while element 820may be operable to save the invoice in the selected format or a defaultformat.

Element 830 may be operable to open a help or messaging interface thatallows the user to gather information about bill payment in general,about invoices from the merchant specifically, or to send a message tothe merchant.

Element 840 indicates the type of invoice (for example, a taxabletransaction, a tax-exempt transaction, a charitable contribution, and soon).

Element 845 shows information regarding the customer such as name andmailing address. Similarly, element 850 shows information regarding theinvoicing business, including the name and mailing address.

Element 855 shows the metadata of the invoice, including invoice number,reference, GST number of the invoicing business, date on which theinvoice was issued, and date on which the invoice is due. Element 855also shows the amount of time remaining before the invoice is due.

Element 860 shows the line items of the invoice, including, for eachitem, a description, a quantity, a unit price, and an amount. Inembodiments, more or fewer information for each line item is shown.

Element 870 shows total detail data for the invoice. As shown in element870, the subtotal, GST, and amount due are shown. The specific lineitems shown in element 870 may vary based on the location of thebusiness user, the location of the customer, and business user options.The subtotal may be determined by summing the amounts shown in element860. The GST may be calculated based on tax rules for the location ofthe business. The amount due may be determined by summing the line itemsin element 870.

When a user (e.g., debtor) receives an online invoice or paymentrequest, the user may be presented with the UI 800 including element805, which may include a link to a dialog listing participating banksFor example, if the user has not yet selected a default bank, the UI900, shown in FIG. 9, may be presented in response to a selection of the“Pay Now” button (element 805) by the user. After setting a defaultbank, the user may be immediately redirected to the bank for payment ofthe invoice (e.g., as shown in the UI 1000 of FIG. 10), or returned tothe UI 800. After a default bank has been set, operation of the element805 may redirect the user's device to that bank for payment.

FIG. 9 is an interface diagram depicting an example user interface 900for configuring bank options for a customer. The UI 900 includeselements 910-940, as discussed in more detail below, and may bepresented to a user during initial configuration, in response toreceiving an invoice, or in response to a request from the user.

Element 910 is a title, showing that the user is currently on a “BankConfiguration” screen. Similarly, element 920 is an informationalmessage, requesting that the user select a default bank for invoicepayments.

Element 930 includes radio buttons to allow the user to select a bankfrom a list of banks for the user. In other example embodiments, adrop-down list or other selector is used. The set of banks available forselection may be the set of banks with which the payment initiator hasexchanged encryption keys, a set of banks identified based oninformation about the user (e.g., the location of the user), a set ofbanks identified based on information about the transaction (e.g., thecurrency of the transaction), a set of banks identified based oninformation about the payee (e.g., the location of the payee or banksassociated with the payee), or any suitable combination thereof. The setof banks may be accessed from a database, such as the database 380A orstorage 450A.

Element 940 is a button operable to confirm the selected bank. Forexample, the user may select the radio button corresponding to “ABCBank” shown in the element 930, then press the “Done” button of element940 to save the selection. In other example embodiments, the choice ofbank is made without a second confirmation action.

A cookie may be stored on the debtor's machine so that any subsequentinvoices the debtor receives from the payment initiator willautomatically invoke the preference to use their chosen bank to pay theinvoice. This may be changed by the user selecting another bank andreplacing the information stored in the cookie.

The payment mechanism through the direct bank transfer may be anendpoint exposed by a financial institution (and shared with aparticular payment initiation partner) to which a debtor receiving apayment request is redirected, should they choose to pay using theirbank. The direct bank transfer may avoid using a third-partyintermediary, such as a credit card transaction service. The paymentmechanism may accept the payment details, authenticate the onlinebanking user into Internet banking, and may present the paymentinformation for confirmation by the debtor. Benefits of this service mayinclude:

-   -   Participating financial institutions have presence and utility        in front of not only businesses, but a business's customers.    -   The financial institution processes the payment via Internet        bill payment functions, rather than the payment being processed        via scheme (e.g., credit card payment processing).    -   The financial institution controls who can present the payment        functionality by requiring a signed and encrypted payment        message that uses a key exchange.    -   Reduced merchant fees for the biller, and no merchant account        requirement. For example, the merchant does not pay credit card        fees on an ACH transaction.    -   Greater business satisfaction—merchant gets paid without        charge-back concerns, customer can pay larger sums via Internet        banking    -   Drives debtor back into Internet banking rather than payment        gateway.    -   Debtor is not forced to pay surcharge (becoming more common with        payment gateways that collect payment via credit card)

Below is a table of entities that may be common to both the financialinstitution (FI) and the payment initiator (PI):

Name Source Type Description Global FI Public Key FI Byte[ ] Public Keyfor Financial Institution PI Public Key PI Byte[ ] Public Key forPayment Initiator Provider ProviderCode PI String(50) Used so that FIcan recognize partner before decryption. ProviderID PI String(50) Usedso that FI can confirm recognition of payment initiator afterdecryption.

Below is a table of FI entities:

Name Source Type Description Global FI Private Key FI Byte[ ] PrivateKey for Financial Institution

Below is a table of PI entities:

Name Source Type Description Global PI Private Key PI Byte[ ] PrivateKey for Payment Initiator Payment AccountNumber PI String(50) Payee'saccount number DueDate PI Date Date the payment is due. (ISO 8601) PayeePI String(50) Payee's name Reference PI String(50) Invoice referenceAmount PI Decimal Amount to pay Currency PI Char(3) Currency (ISO 4217)

Once a debtor has chosen their bank, the payment mechanism is handedover to the financial institution to complete. Transfer to the financialinstitution may be done via a secure hypertext transfer protocol (HTTPS)POST, triggered by the user clicking element 905 once a bank has beenselected. In order to complete the payment, the user may authenticatewith the bank using a valid Internet banking user account.

Data may be transferred from the payment initiator to the financialinstitution via the user's browser when the user chooses to make apayment. The data transferred may be sent in one direction, from thepayment initiator to the financial institution. The communicationprotocol may be designed to avoid any server-to-server communicationbetween the financial institution and payment initiators, meaning thatvirtual private networks (VPNs) or other secure infrastructure do notneed to be implemented. The data is transferred via the user's webbrowser client, as an encrypted, signed blob contained within aJavaScript object notation (JSON) data structure.

The payment initiator assembles a blob of data containing informationabout the payment that the user wishes to make. This blob may containpayment details and other sensitive information, and hence is encryptedso the data within is opaque to the client browser transferring thedata.

In some embodiments, the payment data may be transferred using the“Encrypt then MAC” pattern. A symmetric key may be randomly generatedand used to encrypt the payment data. The payment initiator has thefinancial institution's public RSA key that may be used to encrypt thesymmetric key. The financial institution may use its private RSA key todecrypt the symmetric key and in turn use it to decrypt the message.

The payment initiator may have a private RSA key that is used to signmessages sent to the financial institution. The financial institutionmay use the payment initiator's public RSA key to verify that thesignature is valid.

Any suitable cryptographic algorithm may be used, such as AES forsymmetric encryption, RSA for asymmetric encryption, RSA-SHA2 forsigning, and the like. Additionally, for cryptographic keys generatedand used in the system, any key sizes may be used (e.g., AES 256 bits,RSA 2048 bits, SHA 256 bits, etc.).

Any nonce and initialization vectors may be generated from acryptographically secure random number generator. This ensures that thesymmetric encryption will be strong and prevent brute force attacksagainst the encrypted data bytes in the message. In some embodiments,certain default random number generators may not be cryptographicallysecure. Thus, a cryptographically secure algorithm should be chosen(e.g. in C#, the System.Security.Cryptography. RandomNumberGeneratorclass should be used instead of the System.Random class).

The financial institution may store a private RSA key issued and heldonly by the financial institution (e.g., the financial institution'sprivate key) and a public RSA key issued by the payment initiator (e.g.,the payment initiator's public key). Similarly, the payment initiatormay store a public RSA key issued by the financial institution (e.g.,the financial institution's public key) and a private RSA key issued andheld only by payment initiator (e.g., the payment initiator's privatekey).

Packaging a message to send to the financial institution may occur in avariety of manners. For example, the payment initiator may use thefollowing algorithm and/or pseudo-code to package a message for receiptby the financial institution. The JSON Payment containing the sensitivedata may be encrypted and signed, and the resulting MessageContainer maybe sent to the financial institution as a JSON data structure via theuser's browser.

PlainTextDataString = Base64Encode(Payment) IVBytes = GenerateRandomlV() EncryptedIV = RSAEncrypt(IVBytes, FI_PubKey) RandomKeyBytes =GenerateRandomKey( ) EncryptedRandomKey = RSAEncrypt(RandomKeyBytes,FI_PubKey) EncryptedDataBytes = AESEncrypt(PlainTextDataString,RandomKeyBytes, IVBytes) SignatureBytes = Calculate SHA2Signature(EncryptedIV + EncryptedRandomKey + EncryptedDataBytes, PI_PrivKey)MessageContainer.PC = “PROVIDER/XERO” MessageContainer.EIV =Base64Encode(EncryptedIV) MessageContainer.ERK =Base64Encode(EncryptedRandomKey) MessageContainer.Data =Base64Encode(EncryptedDataBytes) MessageContainer.S =Base64Encode(SignatureBytes) MessageContainer.SM = “RSA-SHA2”

Verifying and unpackaging a message upon receipt by the financialinstitution may occur in a variety of manners. For example, upon thereceipt of a message from a payment initiator, the financial institutionmay decrypt and unpack the message to ensure it has come from anapproved payment initiator and has not been tampered with. The followingalgorithm and/or pseudo-code may be used to unpack the MessageContainerand receive the Payment.

EncryptedIV = Base64Decode(MessageContainer.EIV) EncryptedRandomKey =Base64Decode(MessageContainer.ERK) EncryptedDataBytes =Base64Decode(MessageContainer.Data) SignatureBytes =Base64Decode(MessageContainer.S) (Check MessageContainer.SM ==“RSA-SHA2”) VerifySignatureBytes = CalculateSHA2Signature( EncryptedIV +EncryptedRandomKey + EncryptedDataBytes, PI_PubKey) (CheckVerifySignatureBytes == SignatureBytes) IVBytes =RSADecrypt(EncryptedIV, FI_PrivKey) RandomKeyBytes =RSADecrypt(EncryptedRandomKey, FI_PrivKey) PlainTextDataString =AESDecrypt(EncryptedDataBytes, RandomKeyBytes, IVBytes)AccountMapMessage = Base64Decode(PlainTextDataString)

The financial institution may then validate the internals of the paymentto check that it has integrity. For example, this may include:

-   -   Check Payment.ProviderID matches MessageContainer.PC    -   TimeStampUTC is within the tolerance for valid messages, and the        message has not expired    -   The (TimeStampUTC, Nonce) have not been used by the Payment        Initiator, to check the message is not a replay attempt    -   Other validation of message contents

Once the verification and unpackaging operations are successfullycompleted, the user may be shown displays allowing the user to continueto proceed with an Internet payment via internet banking

The example message encryption and packaging described above may allowmessages to pass from the payment initiator to the financial institutionover an untrusted communication mechanism (the user's browser).

The encryption and signing provide guarantees that the payment initiatorlegitimately generated the message, the message was not tampered with orviewed in transit, and the message cannot be replayed. The paymentinitiator can also be assured that only the financial institution willbe able to decrypt the data.

Other security issues include:

Spoofing: It may not be possible for anyone other than the onlineaccounting software server to generate a valid message due to the use ofthe public/private key pair shared between the online accountingsoftware server and the Financial Institution. Any other keys used forencryption may fail the signature verification step.

Repudiation: The payment initiator may sign the data using their privatekey, which is kept secret and held only by them. When the FI receivesthe message and checks the signature using the PI's public key, they canbe assured the PI originally generated the message.

Tampering: The signature check may also prevent tampering in transit. Ifthe initialization vector (IV), key or data is altered, then thesignature check will fail.

Information Disclosure: The payment may contain some sensitiveinformation, such as amounts and account numbers. This may be encryptedusing a one-time-use encryption key. The encryption key may betransmitted in the message, but may be encrypted asymmetrically usingthe FI's public key, which only the FI can decrypt.

Replay: Replay attacks may be prevented by a timestamp and nonce valuethat allows the FI to guarantee it will receive and process a givenmessage only once. If a message arrives with the same timestamp andnonce, the FI may reject the message.

Man-in-the-middle (MiTM): It may be possible for an attacker tointercept the generated JSON from the payment initiator and forward itto the FI before the legitimate user is able to. This may be mitigatedby secure socket layer/transport layer security (SSL/TLS) connectionsbeing used in the user's browser, preventing MiTM on the client side,and the use of a short expiration against the message timestamp. As theuser will not need to perform any action between the message generationand the immediate POST to the FI, the expiration can be kept short.

Denial of Service: This protocol may not provide protection againstdenial of service; an attacker could send large, malformed, or numerousmessages to the FI endpoint and cause a costly signature check ordecryption process to occur. This should be mitigated by using the FI'sstandard brute force detection mechanisms.

Elevation of Privilege: The message transferred from the paymentinitiator to the FI may not convey privileges from one environment tothe other. The user may still have to authenticate independently withthe FI institution site in order to have the option to complete apayment.

An example message sent from the initiator to the financial institutionmay include the following payment information:

Name Type Description ProviderID String(50) FI's identifier for thepayment initiator Currency Char(3) ISO4217 currency code for the paymentAccountNum- String(50) Payee's supplied account ber number. (Numeralsonly) DueDate Date Date payment is due (ISO 8601) Payee String(50) Payeename Reference String(50) Payees's invoice reference Amount DecimalAmount to pay Time- DateTime The time that the stampUTC (e.g. messagewas constructed “2000-12-29T00:00:00Z”) by the caller. Used to expiremessages that have passed a timeout threshold. ISO 8601 NonceString(255) The Nonce value should be unique for all requests with thatTimestampUTC. The nonce allows the server to verify that a request hasnever been made before and helps prevent replay attacks. The server willcache all (ProviderID, TimestampUTC, Nonce) tuples until after theexpiration of the messages, and reject any un-expired messages that havealready been received. ReturnURL String(255) A URL to redirect the(Well-formed absolute user to, upon completion uniform resource locatorof the payment process. (URL))

An example JSON value for the payment message may be as follows:

{ “ProviderID”: “PROVIDER/XERO”, “Currency”: “NZD”, “AccountNumber”:“01013703294839400”, “DueDate”: “2013-07-23”, “Payee”: “Demo Company”“Reference”: “INV-01234”, “Amount”: 124.32, “TimestampUTC”:“2012-12-10700:00:00”, “Nonce”: “A7813747-C47A-496E-8DE6-682D16A457D2”,“ReturnURL”: “https://www.xyz.com/” }

An example message (e.g., MessageContainer) that may be sent from thepayment initiator to the financial institution via the user browser mayinclude the following:

Name Type Description PC String(50) FI's identifier for the paymentinitiator Data Byte[ ] An encrypted blob of data ERK Byte[ ] EncryptedRandom Key The key used to encrypt/decrypt the data blob. Should beencrypted with FI's public key. EIV Byte[ ] Initialization Vector usedwhen encrypting data. Should be encrypted with FI's public key. S Byte[] The signature calculated when running the request signing method overthe Encrypted IV, Encrypted Random Key and Data fields. SM String(50)The method used to calculate the message signature. If not specified,the default of “RSA-SHA2” is assumed.

Each Byte[ ] array may be transmitted as a Base 64 encoded string whenrendered as JSON. An example JSON value for the MessageContainer may beas follows:

{ “PC”: “PROVIDER/XERO”, “Data”: “qas43...==”, “ERK”: “Rxut...==”,“EIV”: “QEDF...==”, “S”: “zyw...==”, “SM”: “RSA-SHA2” }

The payment mechanism provided by the online accounting software servermay facilitate sending payment from the payment initiator to thefinancial institution for the authenticated internet banking user topay. Once the user has been redirected from the payment initiator to thefinancial institution, and the appropriate information has been passed,this action may be completed within the financial institution. The usermay be presented with the payment details, and the user may elect topay. Implementation of this functionality may be left up to thefinancial institution.

In some embodiments, certain preconditions may be required before thefinancial institution will present the proposed transaction to thecustomer, such as:

-   -   The user is authenticated with the FI.    -   The ProviderCode is recognized.    -   The random key can be decrypted with the FI's private key.    -   The request data can be decrypted with the random key.    -   The signature is verified with the financial institution's        public key.    -   The ProviderID is a valid provider.    -   The nonce has not been used before.    -   The data is able to be parsed and all required elements        included.    -   Full payment information is provided.    -   The timestamp is within a valid timeout period.

In some embodiments, certain post-conditions may be required. Forexample, approval of the payment by the customer may be required beforeprocessing the payment continues.

FIG. 10 is an interface diagram depicting an example user interface 1000for paying an invoice from a business, according to some embodiments.The user interface 1000 includes elements 1010-1070, as discussed below.

Element 1010 is a title, showing that the user is currently viewinginformation provided by “ABC BANK.” Similarly, element 1020 is adescription, showing that the user is viewing a page for “INTER-BANKTRANSFER.”

Elements 1030-1050 show the payee (e.g., the business that sent theinvoice using the UI 700), the amount (e.g., the amount of the invoice),and the payment date (e.g., the current date or the due date of theinvoice). In some example embodiments, one or more of the payee, theamount, and the payment date are modifiable by the user. In otherexample embodiments, the user is not allowed to modify the fields.

Element 1060 is a button operable to confirm the details shown inelements 1030-1050, and operable to cause the financial institution totransfer the amount shown in element 1040 from the customer's account tothe business's account shown in element 1030 on the transaction dateshown in element 1050. The financial institution may communicate withthe payment initiator to inform the payment initiator that the paymentwas made or is scheduled to be made on the payment date. Alternativelyor additionally, the financial institution may inform the paymentinitiator that the payment was successfully completed after the transferof funds is complete.

Element 1070 is a button operable to cancel the transfer of funds. Insome example embodiments, the payment initiator is informed that paymentwas not completed. The payment initiator may send one or more additionalmessages to the user to remind the user of the outstanding invoice.

FIG. 11 is a block diagram depicting the flow of data between entitiesfacilitating a transfer of funds, in an example embodiment. As shown inFIG. 11, the user may interact with the accounting software platform tochoose the bank to make payment with. For example, the UI 900 of FIG. 9may be used to make the bank selection, and the selected bank sent tothe accounting software platform via a ChooseBank function 1105. Theaccounting software platform provides a response 1110 to the user. Theresponse may be in the form of a web page informing the user that thebank selection was successfully made. The user then chooses to pay theinvoices via a PayNow function 1115 (e.g., by activating element 805 ofFIG. 8). After receiving the payment command from the user, theaccounting software platform generates request 1120 to the accountingsoftware server. The accounting software server responds by creating anencrypted block of data that includes the information for the user'sbank and an invoice to be paid and sending the encrypted block of datain the response 1125. The response 1130 from the accounting softwareplatform to the user also includes this data, along with an address forredirection. For example, the received web page may include an HTML metatag that causes the page to refresh from a different URL.

Accordingly, the user is redirected 1135 to the internet banking site.The internet banking site sends a response 1140, such as a welcome orlogin web page. The user sends authentication data to the internetbanking site, such as a user name and password. The internet bankingsite sends a response 1150, such as an acknowledgement that the userauthentication was successful, along with a redirection address toanother page within the internet banking site at which the invoice canbe paid. The user is redirected 1155 to the new page, and receives thepage in response 1160 from the internet banking server. The responsepage may include information about the transaction and request forconfirmation from the user to pay the invoice. The user submits theconfirmation 1165 to the internet banking server, which generates arequest to process 1170 the payment to the banking services server. Thebanking services server initiates the processing of the payment andsends an appropriate response 1175 to the internet banking server. Theinternet banking server sends a response 1180 to the user. For example,the user may be presented with a web page indicating that the invoicepayment was successful.

The banking services server or internet banking server sends aconfirmation 1185 to the accounting software platform or accountingsoftware server to inform the accounting software that the invoice hasbeen paid. Accordingly, when the entity that generated the invoice nextaccesses the accounting software, the entity can be informed thatpayment was received.

FIG. 12 is a flowchart of an example method 1200 for facilitating directbank transfers.

In operation 1210, the online accounting software server may present aninvoice and a payment button (such as those shown in FIG. 8) to a clientdevice of a user (e.g., a customer of a business). The invoice mayidentify an amount owed by the user to the business. The payment buttonmay be associated with an option to pay the amount to the businessthrough a particular bank of the user. The particular bank to be usedmay be selected by the user.

In operation 1220, the online accounting software server may receive,from the client device, a request to pay the amount through the user'saccount with the particular bank selected. The request may be made usingthe payment button.

In operation 1230, the request may be used by the online accountsoftware server to redirect the client device to a website of theparticular bank selected, such that the particular bank may determinethe validity of the request to pay the amount through the user's accountand may transfer the amount from the user account to the business's bankaccount.

In operation 1240, the online accounting software server may receive anindication indicating the amount was transferred from the user accountto the business's bank account. The indication may have been sent fromthe bank selected by the user, from which funds were transferred.Alternatively or additionally, the indication may have been sent fromthe bank of the business, to which funds were transferred.

FIG. 13 is a flowchart of an example method 1300 for facilitating directbank transfers.

In operations 1310 and 1320, the payment initiator and a bank exchangepublic keys. For example, the payment initiator and the bank mayexchange public keys via email.

In operation 1330, the payment initiator presents an invoice with apayment button at a client device of a user. For example, the paymentinitiator may send a web page to a web browser on a client device. Asanother example, the payment initiator and the client device mayinteract through a programmatic interface, such as an API, to cause thepresentation of the invoice and payment button to the user.

In operation 1340, the payment initiator receives a request to pay theinvoice. For example, the user may press the payment button, causing anHTTP or API message to be sent to the payment initiator. The request mayinclude information about a user's bank account at the bank, or anindication usable by the payment initiator to access the user's bankaccount information in a database of the payment initiator.

In operations 1350 and 1360, the payment initiator encrypts a datapacket using the bank's public key and signs the data packet with thepayment initiator's private key. The data packet includes informationusable by the bank to process the payment of the invoice. For example,the data packet may include an account number of the user, accountinformation of the entity presenting the invoice, a timestamp for whenthe data packet was created, a valid duration for the request ortimestamp for when the data packet expires, an amount of the invoice,and so on.

In operation 1370, the payment initiator redirects the client device tothe bank. For example, if the client is connected to the paymentinitiator via a web connection, the client's web browser can be directedto load a web page from a website of the bank. As another example, ifthe client is connected to the payment initiator via an applicationinterface, an application of the bank on the client device may bestarted for the user.

In operation 1380, the encrypted data is sent from the payment initiatorto the bank via the client device. For example, the encrypted data canbe sent to the client device from the payment initiator. After theclient has been redirected to the bank, or as part of the redirectionprocess, the bank receives the encrypted data from the client device.

After receiving the encrypted data, the bank decrypts the data using thepayment initiator's public key and the bank's private key. Based on theinformation in the data, the bank presents a user interface to the user,allowing the user to confirm payment. The UI presented to the user maybe prepopulated with information from the invoice, such as the amountand the payee, based on the information extracted from the encrypteddata.

Certain embodiments are described herein as including logic or a numberof components, modules, or mechanisms. Modules may constitute eithersoftware modules (e.g., code embodied on a machine-readable medium or ina transmission signal) or hardware modules. A hardware module is atangible unit capable of performing certain operations and may beconfigured or arranged in a certain manner. In example embodiments, oneor more computer systems (e.g., a standalone, client, or server computersystem) or one or more hardware modules of a computer system (e.g., aprocessor or a group of processors) may be configured by software (e.g.,an application or application portion) as a hardware module thatoperates to perform certain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired) or temporarilyconfigured (e.g., programmed) to operate in a certain manner and/or toperform certain operations described herein. Considering embodiments inwhich hardware modules are temporarily configured (e.g., programmed),each of the hardware modules need not be configured or instantiated atany one instance in time. For example, where the hardware modulescomprise a general-purpose processor configured using software, thegeneral-purpose processor may be configured as respective differenthardware modules at different times. Software may accordingly configurea processor, for example, to constitute a particular hardware module atone instance of time and to constitute a different hardware module at adifferent instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation, and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods described herein may be at least partiallyprocessor-implemented. For example, at least some of the operations of amethod may be performed by one or more processors orprocessor-implemented modules. The performance of certain of theoperations may be distributed among the one or more processors, not onlyresiding within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a SaaS.For example, at least some of the operations may be performed by a groupof computers (as examples of machines including processors), theseoperations being accessible via a network (e.g., the Internet) and viaone or more appropriate interfaces (e.g., APIs).

Example embodiments may be implemented in digital electronic circuitry,or in computer hardware, firmware, software, or in combinations of them.Example embodiments may be implemented using a computer program product,e.g., a computer program tangibly embodied in an information carrier,e.g., in a machine-readable medium for execution by, or to control theoperation of, data processing apparatus, e.g., a programmable processor,a computer, or multiple computers.

A computer program can be written in any form of programming language,including compiled or interpreted languages, and it can be deployed inany form, including as a stand-alone program or as a module, subroutine,or other unit suitable for use in a computing environment. A computerprogram can be deployed to be executed on one computer or on multiplecomputers at one site or distributed across multiple sites andinterconnected by a communication network.

In example embodiments, operations may be performed by one or moreprogrammable processors executing a computer program to performfunctions by operating on input data and generating output. Methodoperations can also be performed by, and apparatus of exampleembodiments may be implemented as, special purpose logic circuitry(e.g., a FPGA or an ASIC).

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. Inembodiments deploying a programmable computing system, it will beappreciated that that both hardware and software architectures requireconsideration. Specifically, it will be appreciated that the choice ofwhether to implement certain functionality in permanently configuredhardware (e.g., an ASIC), in temporarily configured hardware (e.g., acombination of software and a programmable processor), or a combinationof permanently and temporarily configured hardware may be a designchoice. Below are set out hardware (e.g., machine) and softwarearchitectures that may be deployed, in various example embodiments.

FIG. 14 is a block diagram of a machine in the example form of acomputer system 1400 within which instructions, for causing the machineto perform any one or more of the methodologies discussed herein, may beexecuted. In alternative embodiments, the machine operates as astandalone device or may be connected (e.g., networked) to othermachines. In a networked deployment, the machine may operate in thecapacity of a server or a client machine in server-client networkenvironment, or as a peer machine in a peer-to-peer (or distributed)network environment. The machine may be a personal computer (PC), atablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), acellular telephone, a web appliance, a network router, switch or bridge,or any machine capable of executing instructions (sequential orotherwise) that specify actions to be taken by that machine. Further,while only a single machine is illustrated, the term “machine” shallalso be taken to include any collection of machines that individually orjointly execute a set (or multiple sets) of instructions to perform anyone or more of the methodologies discussed herein.

Example computer system 1400 includes a processor 1402 (e.g., a centralprocessing unit (CPU), a graphics processing unit (GPU), or both), amain memory 1404, and a static memory 1406, which communicate with eachother via a bus 1408. Computer system 1400 may further include a videodisplay device 1410 (e.g., a liquid crystal display (LCD) or a cathoderay tube (CRT)). Computer system 1400 also includes an alphanumericinput device 1412 (e.g., a keyboard), a user interface navigation device1414 (e.g., a mouse or touch sensitive display), a disk drive unit 1416,a signal generation device 1418 (e.g., a speaker), and a networkinterface device 1420.

Disk drive unit 1416 includes a machine-readable medium 1422 on which isstored one or more sets of instructions and data structures (e.g.,software) 1424 embodying or utilized by any one or more of themethodologies or functions described herein. Instructions 1424 may alsoreside, completely or at least partially, within main memory 1404,within static memory 1406, and/or within processor 1402 during executionthereof by computer system 1400, with main memory 1404 and processor1402 also constituting machine-readable media.

While machine-readable medium 1422 is shown in an example embodiment tobe a single medium, the term “machine-readable medium” may include asingle medium or multiple media (e.g., a centralized or distributeddatabase, and/or associated caches and servers) that store the one ormore instructions or data structures. The term “machine-readable medium”shall also be taken to include any tangible medium that is capable ofstoring, encoding or carrying instructions for execution by the machineand that cause the machine to perform any one or more of themethodologies of the present technology, or that is capable of storing,encoding or carrying data structures utilized by or associated with suchinstructions. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, andoptical and magnetic media. Specific examples of machine-readable mediainclude non-volatile memory, including by way of example semiconductormemory devices, e.g., Erasable Programmable Read-Only Memory (EPROM),Electrically Erasable Programmable Read-Only Memory (EEPROM), and flashmemory devices; magnetic disks such as internal hard disks and removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Instructions 1424 may further be transmitted or received over acommunications network 1426 using a transmission medium. Instructions1424 may be transmitted using network interface device 1420 and any oneof a number of well-known transfer protocols (e.g., HTTP). Examples ofcommunication networks include a local area network (LAN), a wide areanetwork (WAN), the Internet, mobile telephone networks, Plain OldTelephone (POTS) networks, and wireless data networks (e.g., WiFi andWiMAX networks). The term “transmission medium” shall be taken toinclude any intangible medium that is capable of storing, encoding orcarrying instructions for execution by the machine, and includes digitalor analog communications signals or other intangible media to facilitatecommunication of such software.

Although an embodiment has been described with reference to specificexample embodiments, it will be evident that various modifications andchanges may be made to these embodiments without departing from thebroader spirit and scope of the technology. Accordingly, thespecification and drawings are to be regarded in an illustrative ratherthan a restrictive sense. The accompanying drawings that form a parthereof, show by way of illustration, and not of limitation, specificembodiments in which the subject matter may be practiced. Theembodiments illustrated are described in sufficient detail to enablethose skilled in the art to practice the teachings disclosed herein.Other embodiments may be utilized and derived therefrom, such thatstructural and logical substitutions and changes may be made withoutdeparting from the scope of this disclosure. This Detailed Description,therefore, is not to be taken in a limiting sense, and the scope ofvarious embodiments is defined only by the appended claims, along withthe full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter may be referred toherein, individually and/or collectively, by the term “invention” merelyfor convenience and without intending to voluntarily limit the scope ofthis application to any single invention or inventive concept if morethan one is in fact disclosed. Thus, although specific embodiments havebeen illustrated and described herein, it should be appreciated that anyarrangement calculated to achieve the same purpose may be substitutedfor the specific embodiments shown. This disclosure is intended to coverany and all adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the above description.

What is claimed is:
 1. A method comprising: receiving, from a machine, arequest to pay an amount to an entity through a user account; responsiveto the request to pay: sending encrypted data to the machine; andredirecting the machine to a website associated with the user account;and receiving an indication, from the website, that the amount wastransferred from the user account to an account of the entity.
 2. Themethod of claim 1, wherein the encrypted data includes at least one ofthe following: data identifying a bank of the user, an identity of theuser, the amount, a description associated with an invoice, and dataidentifying the account of the entity.
 3. The method of claim 1, whereinthe transfer of the amount from the user account to the account of theentity does not transfer the amount through an intermediate account. 4.The method of claim 1, wherein the indication indicates that the amountwas transferred via Automated Clearing House (ACH).
 5. The method ofclaim 1, wherein: the account of the user is a bank account; and theencrypted data is encrypted using a public key of the bank.
 6. Themethod of claim 5, further comprising receiving the public key of thebank from the bank.
 7. The method of claim 6, wherein the encrypted datais signed using a private key.
 8. The method of claim 7, furthercomprising sending a public key corresponding to the private key to thebank.
 9. The method of claim 1, further comprising: receiving, from theentity, a payment request, the payment request including an identity ofthe user, the amount, a description associated with the invoice, anddata identifying the account of the entity; and presenting the paymentrequest and a payment button on the machine, the payment requestidentifying the amount owed by the user to the entity, the paymentbutton being associated with an option to pay the amount to the entitythrough a bank of the user.
 10. The method of claim 1, furthercomprising: presenting an invoice and a payment button to a clientdevice of a user, the invoice identifying an amount owed by the user toan entity, the payment button being associated with an option to pay theamount to the entity; and in response to activation of the paymentbutton, presenting a user interface operable to select a financialinstitution associated with the user account.
 11. A system comprising: amemory; and one or more modules coupled to the memory and configured to:receive, from a machine, a request to pay the an amount to an entitythrough a user account; responsive to the request to pay: send encrypteddata to the machine; and redirecting the machine to a website associatedwith the user account; and receive, from the website, an indicationindicating the amount was transferred from the user account to anaccount of the entity.
 12. The system of claim 11, wherein the encrypteddata includes at least one of the following: data identifying a bank ofthe user, an identity of the user, the amount, a description associatedwith an invoice, and data identifying the account of the entity.
 13. Thesystem of claim 11, wherein the transfer of the amount from the useraccount to the account of the entity does not transfer the amountthrough an intermediate account.
 14. The system of claim 11, wherein theindication indicates that the amount was transferred via AutomatedClearing House (ACH).
 15. The system of claim 11, wherein: the accountof the user is a bank account; and the encrypted data is encrypted usinga public key of the bank.
 16. The system of claim 11, wherein: the oneor more modules are further configured to: generate a set of banks basedon availability of a public key for each bank of the set of banks in adatabase; present a user interface operable to select a bank from theset of banks; and detect a selection of the bank in the user interface;and the website associated with the account of the user is associatedwith the selected bank.
 17. The system of claim 11, wherein the one ormore modules are further configured to: retrieve data for the paymentrequest from a database; present a request interface to the entityoperable to request payment of the payment request, the user interfaceincluding at least a portion of the retrieved data; and receive arequest for payment of the payment request generated via the requestinterface.
 18. The system of claim 17, wherein the one or more modulesare further configured to: responsive to the request for payment of thepayment request, send an electronic communication to the user, theelectronic communication including a link to a web page hosted by thesystem; and wherein the presenting of the payment request and thepayment button are in response to an operation of the link.
 19. Thesystem of claim 11, wherein the one or more modules are furtherconfigured to: receive a login by the user; and present the paymentrequest to the user in response to the login.
 20. A non-transitorymachine-readable storage medium storing instructions which, whenexecuted by one or more processors, cause the one or more processors toperform operations comprising: receiving, from a machine, a request topay an amount to an entity through a user account; responsive to therequest to pay: sending encrypted data to the machine; and redirectingthe machine to a website associated with the user account; and receivingan indication, from the website, that the amount was transferred fromthe user account to an account of the entity.